Backend CI guideline

This section describes how to proceed with branching, PR and releasing for any features developed for Navida PRO.

Branching strategy

For further development of Navida PRO, a trunk-based development approach has been selected for the branching strategy. For detailed description please check Google, for example this link.

Key assumptions:

• developers should merge (relatively) small pieces of code with the target, long living branch - develop in case of Navida PRO
• any update of the develop branch needs to happen via a PR process (see below for details)
• any breaking change needs to be guarded by a feature-flag (see below for details)
• bugfixes are non-breaking by nature and should be merged without feature-flagging in place. If not the case - handle individually
• develop branch needs to be shippable at any moment

Deployment Process

Environments:

• We have Four environments in place for the deployment of services
• Dev Area
  • All the ferature branch changes can be pushed to dev area with a tag prefixed with dev_. Pipeline will trigger on tagging update to the ferature branch ,and gthe changes will be deployed automatically into the cluster. Development team should collaboratively communicate about this to avoid confusions of possible overrides

• Tst Area
  • PR merge to the release branch ( currently kept as dev ) will result a pipeline trigger and an automated deployment of the services to this area. Basically this means a production ready version of the service, that can be pushed to the other environments.

• Pre Prod Area
  • SAPM/SAPW areas will get an automatic refresh of the services , upon successful tagging of the release branch. Deployments will be automatic, but any addition / modification to the configurations should be communicated via Jira Ticket / confluenece documentation to ITScare .

• Production Area
  • production push of services are handled by Jira ticket and based on the required tags , which are successfully tested and verified in the pre-prod area